In simple terms, HENNGE Secure Transfer serves as a secure data transfer platform, offering users the ability to send and receive data with enhanced security measures. So if you want to send large files such as media data to external contacts with extra layers of security, this is the product for you!

Yes. Generally employees will send data over email, but there are size limitations. Common mail providers can only send files up to around 50 megabytes. But increasingly people need to send larger files, such as one gigabyte or more. In a world where traditional email services impose size limitations on file transfers, our platform fills the gap by enabling users to securely transmit large files, ensuring confidentiality and integrity throughout the process.

Moreover, our emphasis on offering this as a temporary data transfer is a key selling point and adds an extra layer of security. Our users like that their data is not stored indefinitely, thus mitigating privacy concerns. In a nutshell, HENNGE Secure Transfer caters to the evolving needs of modern enterprises, facilitating seamless communication and collaboration while safeguarding sensitive information.

From a back-end perspective, our infrastructure revolves around Amazon Web Services (AWS) and Kubernetes, enabling scalable and reliable deployment of our services. We leverage GitHub Actions and ArgoCD for streamlined code management and deployment workflows, while Python and Golang serve as the primary programming languages for back-end development. Additionally, Terraform facilitates infrastructure provisioning, ensuring consistency and efficiency across our deployments.

On the front-end, we use the most recent versions of React library with TypeScript combining it with the Styled-components CSS library, always aiming for a high standard of clean code. Our commitment to quality is reflected in our rigorous testing approaches for E2E and unit testing. For E2E testing we use TestCafe with BrowserStack and as of recently we started adopting Playwright with a behavior-driven development (BDD) testing style using the Cucumber framework with Gherkin scenarios. For unit tests we use Jest aiming for a comprehensive coverage of our code base. I think that together this tech stack empowers us to deliver a really strong and bug-free product experience.

The team embraces the Scrum methodology (Editor note: Scrum is an agile project management framework that helps teams structure and manage their work through a common set of values, principles, and practices). And we follow two-week development life cycles called Sprints. Every Sprint starts with a collaborative planning session to outline our objectives and priorities for the upcoming cycle. There's always someone in the team acting as Scrum master to oversee things, to remove barriers and keep things moving as smoothly as possible.

At the end of each sprint, we conduct thorough reviews to assess our progress and iterate on our approach. This encourages continuous improvement and alignment with our wider product roadmap.

For the back-end, we sometimes release a few times a week but we aim to keep them as small as possible so there's less stress with people deploying new things every two weeks.

Users get used to a certain UX so for the front-end we have to be mindful of sudden changes. We use sprint planning to split our projects into small deliverables that can be released to production within the span of two weeks. Once a project has been fully implemented we enable it using feature flagging. That way we can maintain a smooth flow of new content and enable it when it’s ready.

There are CI pipelines that involve rigorous testing, including unit tests and integration tests before pull requests (PRs) can be merged. After merging the PRs, deployment to the staging environment happens, where everyone can test all functionalities. In the deployment process, QA testing is also triggered, and automation of these processes is underway. Prior to production releases, manual checks are conducted by developers on core features to ensure they remain intact. Additionally, new features undergo review and approval by the Product Planning and Research (PPR) and Customer Success (CS) teams before production releases.

I believe collaboration lies at the heart of our approach at HENNGE, and the Secure Transfer team is no exception. The product team consists of several teams including back-end and front-end engineers, UI/UX designers, and PPR. We maintain close communication and collaboration, and all of us work as one product team. Team-wise, it’s a very flat structure and open culture where everyone shares their opinions and respects one another to ensure we keep creating value for customers.

It’s great because everyone joins crowd meetings and can input. We have certain integrations with other services in HENNGE. So it requires us to actually talk to the developer teams and try to figure out the middle ground. For example, making sure things don't break on our end that might break on their end and vice versa. There's a lot of open discussion and I’ve never felt like I was unable to approach or put a question to any other team member.

Agreed. We try to be as open and transparent as possible between the teams. We have a multitude of collaboration-focused meetings that any HENNGE team can join. These are optional but still attract a lot of participants, with subjects ranging from discussions about newly-implemented features to discussing newly-released technologies that we could adopt within our products.

Undoubtedly, one of the most exciting aspects of working on Secure Transfer lies in the diversity of challenges we encounter. The realm of data transfer services offers a multitude of opportunities for innovation, allowing us to explore new technologies and solutions to address evolving user needs.

However, with this diversity comes the challenge of ensuring accessibility and consistency across our product offerings. We strive to maintain a user-centric approach, addressing accessibility concerns and accommodating diverse user preferences, such as screen reader compatibility and keyboard navigation. I’d say our commitment to continuous improvement requires a disciplined approach to testing and quality assurance, ensuring that every release meets stringent standards for reliability and performance.

As the product owner, the challenge lies in translating customer feedback and market demands into actionable tasks while also introducing new value propositions. Convincing customers of novel ideas amidst competition is demanding.

When I joined, we rebuilt the entire system from scratch. It took a few years but ultimately we secured a lot more traffic and reached 9 million downloads. Seeing progress like this with tangible results is super exciting and rewarding.

The product is inherently interesting for me as where I’m from there is a different office culture when it comes to sending emails and data. It’s always interesting when we send something out to the Japanese market and learn that it’s not 100% meeting their needs. Receiving real world feedback is valuable as it helps the team create a better product, and for me personally, gain cool insights into the minds of Japanese users.

First and foremost we prioritize creating value, recognizing that what I find valuable may differ from others. Our team's diversity often leads to unique ideas not explored by competitors. While user feedback is crucial, fostering a culture of idea-sharing among team members is equally important.

Internal teams are also using our product, so before releasing new features we involve HENNGE employees, including sales and support teams, as beta-testers. Their firsthand experience with customers provides invaluable feedback. We conduct meetings, both online and in-person, even visiting different offices in Japan to gather insights directly. This collaborative approach ensures that our products align with market needs and user preferences.

No, it’s pretty simple. If we want to adopt a new technology, we first run a proof of concept and make sure that it is feasible for the infrastructure. We might run some prototypes and make sure everything works fine with existing services but basically anyone who wants to propose something new can bring in a POC and it will be considered.

For example, Liam mentioned that we use Kubernetes. We actually used to use Elastic Container Service, but he proposed Kubernetes as a better solution. They both have pros and cons but Liam was able to clearly show how there were certain features in Kubernetes that would allow for better performance and deployment for our needs.

It was actually a big change that required replacing the entire infrastructure. But there were benefits reaching beyond just our team that allowed us to fast-track the process thanks to HENNGE’s open communication.

In terms of personality I’d say we all share a love for anything techy. People who are open to receiving peer review guidance and feedback, both positive and negative, because they understand that it’s for the benefit of the team will do well. And I’d say self-driven people who can also take ownership of their work with a keen eye for ways to constantly improve the product for the ultimate benefit of our users.

Everyone is working to excel at their job but not just to please their managers. We are doing it because we want to do a good job and take pride in achieving great results together.

Yes, I agree. It’s laid back but we also work hard to get things done. We can work remotely, but have a weekly office day and often go for lunch together so I think people who enjoy being an active part of the team will enjoy it too. We have a lot of company supported social events like the recent cherry blossom hanami party where we can get to know each other and further build that team trust and bond – there’s always something happening!